Complexity pass cut three comment blocks; the correctness pass that followed
found one of the cuts had made the file worse, so that one is reverted here
rather than shipped.

Kept cut: the test carried a three-line block restating the extension's own
comment and quoting measurements from a single run. The commit that introduced
the latch already holds those numbers, and a test file is read every time
someone touches it.

Reverted cut: the seam's comment is back to "Test seam — for unit tests that
want to clear the once-per-process latch". Shortening it to describe the body
dropped the only thing not derivable from the code — why a production module
exports this at all — which is the question the next reviewer asks. The
restored wording is also byte-identical to the same seam in
cc-version-normalize, which is where this pattern comes from.

Dropped a hard count ("Ten earlier tests") from the test comment: accurate
today, silently wrong the moment anyone adds a case, and the invariant does
not need the number.

Co-Authored-By: Claude <noreply@anthropic.com>

The extension's own header claimed "the proxy is the only component that
sees every request byte-for-byte" — 259 lines above the gate that
contradicts it. `onRequest` selects on the request BODY carrying a
`messages` array, so it records `/v1/messages` and nothing else.

That ordering is what makes it worse than a misleading name. A reader who
does the right thing and opens the source hits the universal claim first
and stops, so being careful returns a false confirmation.

**Which route the gate actually drops.** Only two paths reach the pipeline
at all: `/v1/messages` and `/api/claude_cli/bootstrap` (`server.mjs:707`).
Everything else — worker events, RC credentials, OAuth — is relayed by
`handlePassthrough`, which parses nothing, so it never reaches this hook
and is not the gate's doing. The gate's live customer is bootstrap, whose
bodies carry no `messages` array. A first draft of this comment said a
worker-events POST "returns there", which named a mechanism the routing
does not have — the same defect this commit exists to fix, in the
replacement.

Nothing pinned the scope either. The gate could be widened or dropped and
no test would say so, leaving the header as the only statement of what the
corpus covers. The new case asserts a non-Messages body writes nothing
while capture is ENABLED, with a premise that a Messages body still
writes, so it cannot pass because capture was simply off. Widening the
gate to `!ctx.body` fails it and fails nothing else.

Each ctx in that case carries its own session id. The boot record is
tracked per CAPTURE KEY, derived from the session id — not once per
process — so reusing a sibling's id burns the record that sibling asserts
on. A first draft did exactly that and was "fixed" by placing the case
last, which is a comment where an invariant belongs: nothing stops the
next capture-writing case being appended above the sibling. With distinct
ids the case passes in any position, measured first and last.

The directive and the replay/cache-sim tools the header cited are not in
the tree and never were, on any ref. Marked as such rather than re-flowed
unchanged, since a commit about comment truth should not re-affirm a
dangling pointer.

No README change: the extension has no README presence upstream, and
adding its first documentation is different work from correcting a claim
that is wrong.

10/10 in test/request-capture.test.mjs.

Co-Authored-By: Claude <noreply@anthropic.com>

The early return sits below the header strip and below the ctx.meta
annotation, and nothing said so. Hoisting it three lines up is the obvious
"collapse the early exits" edit, and it silently turns the guard off after
the first request of the proxy's life: cache-telemetry spreads that
annotation into every request's session JSON and the statusline reads
auto_1m_detected back out of it, so in strip mode the token stops being
removed from the wire and the guard goes invisible in telemetry, with the
suite still green.

Mutation-checked. With the latch hoisted above the annotation the new assert
fails "request 1 lost its annotation" (expected true, actual undefined).
Three earlier cases in the file fail under that mutation too, but only by
accident of file order and shared module state, and their message
("Cannot read properties of undefined") points nowhere near the cause.

Also trims the comment over the latch to the one clause the code does not
already say.

For the record, the latch's unit is the module instance, not the process:
loadExtensions cache-busts its import on every call, so an extension reload
re-arms the advisory instead of silencing it for the process lifetime.
Measured by importing the module twice under two query strings and counting
the lines: 1 after two requests on one instance, 2 after the re-import.

Co-Authored-By: Claude <noreply@anthropic.com>

A complexity pass over the branch diff. No behaviour change; the assertions
are the same ones, restructured.

request-capture.mjs: the SCOPE block spent four of its six lines on routes
that never reach this hook, and a further two announcing that a directive
and two tools are absent from the tree. Deleting the dangling pointer is
what makes the header true; a note about a file that does not exist is not
something a reader can act on. The gate keeps one statement of what it
drops, in the file header, not a shouting duplicate three lines above the
predicate that reads itself.

test/request-capture.test.mjs: an eight-line preamble, three lines of which
argued that the case should exist. The case name is that argument.

test/proxy-auto-1m-guard.test.mjs: an array collected across one loop only
to be re-walked by a second. The annotation assert moves into the loop that
makes the requests. Mutation-checked after the move: with the latch hoisted
above the ctx.meta write the case still fails "request 1 lost its
annotation" (expected true, actual undefined), the same signal and the same
message as before the restructure.

34/34 in the two touched files.

Co-Authored-By: Claude <noreply@anthropic.com>

Two claims on this branch described behaviour the code does not have.

request-capture's SCOPE comment said the body gate is what drops
/api/claude_cli/bootstrap. It is not. The extension declares no `routes`,
so the pipeline's route filter defaults to ["messages"] and never calls the
hook for a bootstrap-tagged request at all. Measured: driving runOnRequest
with route "messages" reaches the hook, route "bootstrap" does not. The
gate is what scopes an UNTAGGED caller, which appliesToRoute admits on
purpose for embedders and legacy tests.

That is the third draft of this comment to name a routing mechanism that
does not exist, and the second to survive a review pass, so the case now
pins the half that does the work: a MESSAGES body on the bootstrap route,
driven through runOnRequest so the body gate cannot be what drops it.
Mutation-checked — declaring routes ["messages", "bootstrap"] fails it with
"the bootstrap route reached the capture hook" and fails nothing else
(9 pass / 1 fail).

The advisory latch is per MODULE INSTANCE, not per process. loadExtensions
cache-busts its imports, so a reload re-arms it — which is the behaviour
you want, and the same boundary this repo already documents twice
elsewhere, once in the other file this branch touches. Measured: 1 line
after two requests on one instance, 2 after a re-import. The seam comment
and the case name say so now, and the directive's warn row carries the
frequency it was silent about.

Also: the advisory text does vary, by one clause, between warn and strip.
"The advice never changes" is the true form of that claim.

34/34 in the two touched test files.

Co-Authored-By: Claude <noreply@anthropic.com>

Complexity pass over the second round: three comment blocks carried their
facts in one more line than they need, and the premise assertion said
"not empty" as notDeepEqual against a literal empty array across three
lines. assert.ok on the length is one line and states the intent.
Mutation-checked after the rewrite: forcing isEnabled false still fails it
with "premise: capture is on, so a Messages body must write".

The README's mode table described warn as emitting a stderr line, which an
operator reads as one per detection. It is now latched, so the table says
so. The CHANGELOG entry is left alone: it records what shipped at the time
and is not a live description of behaviour.

34/34 in the two touched test files; 1948 pass / 0 fail across the suite
before this comment-only change.

Co-Authored-By: Claude <noreply@anthropic.com>

The mode summary at the top of auto-1m-guard read "stash annotation +
stderr line", 96 lines above the latch that stopped it being one per
request. That is the same defect, in the same shape, as the header this
branch corrects in request-capture: a reader who opens the source hits the
summary first and stops. It says "latched stderr line" now.

Dropped the claim that the advisory's text never varies. The ADVICE
constant does not, but the line written below it appends a clause in strip
mode, and the reason to latch does not need the claim: a repeat carries
nothing the first line did not.

Two test-hygiene fixes, both measured:

- the case left the latch set, so its position in the file was an unguarded
  invariant. Appending a probe case that expects the advisory: 1 with the
  reset in the finally, "appended case saw 0 advisories" without it. The
  probe was temporary; the reset is what stays.
- the stderr stub returned true for every write, so any diagnostic emitted
  while it was installed vanished. It forwards non-matching writes now:
  probed, a line written inside the stub reaches the real stream while the
  advisory is still counted.

The session ids in the capture case buy failure isolation, not what the
comment claimed: neither negative call writes under unmutated code, so
nothing is "burned" there. _bootWrittenFor is module-scoped, so what
distinct ids actually prevent is a MUTATION's write landing on a sibling
case's boot record.

CHANGELOG gains an Unreleased entry: the advisory is user-visible output
and an operator who greps for it after upgrading gets one line where they
used to get thousands.

NOT taken: the review called "Order 60 — after bootstrap-defense (45)"
moot, on the grounds that bootstrap-defense is routed to bootstrap and this
hook never sees that route. Measured through runOnRequest with three
metas: route "messages" runs request-capture alone, "bootstrap" runs
bootstrap-defense alone, and an UNTAGGED ctx runs BOTH, in order.
appliesToRoute returns true for a missing route, so the ordering governs
exactly the untagged caller the SCOPE block above it exists to describe.

34/34 in the two touched test files.

Co-Authored-By: Claude <noreply@anthropic.com>

Its sibling two asserts down says its piece in one line; this one spent
two on a clause the shorter form already carries.

NOT taken, and it is the largest cut on the table: the env save/restore
dance in this file is now on its third copy, and one helper would take
about twelve lines out of the file. Two of those three copies belong to
tests this branch did not write, and both review rounds have already
flagged this PR for carrying a second change its title does not name.
Adding an unrelated test refactor to it makes that worse, not better.

34/34 in the two touched test files.

Co-Authored-By: Claude <noreply@anthropic.com>

runOnRequest defaults `routes` to `["messages"]`, so the value changes
nothing. What it changes is who can see it: the SCOPE note at the top of this
file reasons about that default, and an inherited one is invisible to anyone
widening the corpus from the export.

Both other extensions that rely on the same default spell it out
(jsonl-session-mirror, image-retry-circuit-breaker), so this is the file
matching the two beside it rather than a new convention.

mutation: widening it to ["messages", "bootstrap"] fails
"the bootstrap route reached the capture hook"; 10/10 restored.
GREEN: 34/34 across the two touched files

Co-Authored-By: Claude <noreply@anthropic.com>

Review measured the pre-fix behaviour rather than taking the claim: one
`loadExtensions()` call plus five detected requests emitted ONE advisory, and
two `loadExtensions()` calls emitted two. So the old latch re-armed once per
extension RELOAD -- bounded by how often someone saves a file under
proxy/extensions/, not by traffic.

That wording was the sole stated justification for the change and it sat in the
shipped CHANGELOG. The change is still right; the reason now says what was
measured.

Also here: the two translated READMEs still described the pre-latch behaviour,
so they contradicted all three English documents. Pre-existing drift the latch
work never reached, corrected while the section is open.

The extension comment now points at `process.env`, which is how server.mjs and
request-capture.mjs keep the same kind of reload-durable state, so a reader
meets the second idiom deliberately instead of finding it.

GREEN: 35/35 across the two touched test files

Co-Authored-By: Claude <noreply@anthropic.com>